Security management issues are getting more difficult to administer when database systems transform from centralized systems to distributed ones.
For centralized database management systems there are a number of ways security administrators can establish and maintain DBMS (Database Management System) security. These include:                Manage users, roles, logins, profiles, groups and aliases        Manage password security        Grant and revoke roles to/from users        Grant and revoke system and object-level (such as tables and stored procedures) privileges        Use DBMS views to limit the rows and columns that users (or groups of users) can access        
Once authorized to access the database and by using internal DBMS security features, a user's access to the specific tables and columns of data making up the database is secure. However, much of the effort required to translate the security rules and policies placed on the database to a subset of the data (and related schema) on a database is manual and requires lots of resources.
Because of the laborious nature of the security management process, it is a common practice for applications to connect to the database server with a single, global user ID that was defined in the DBMS as having all permission (select, update, and delete) for all objects (tables, views, and stored procedures). In this scenario, the application is responsible for authenticating individual users and enforcing whatever granularity of control is required at the user level. Such an implementation enables “technology adept” users to easily bypass the control provided by the application and access any data desired. Also, this exposes enterprises to the risk that inconsistencies in security could be established for users who access different tools.
Public Key Infrastructures (PKIs), which are prior art for security material management, generally use Secure Socket Layer (SSL) protocol to protect communications in transit between clients and servers. The basic idea of PKIs is to establish trust between parties by issuing certificates that are trusted by both parties. PKIs are used for managing security of client/server and Internet systems. However, the certificates of this kind are laborious to administer when systems grow large and become more complicated. Especially, the systems don't scale up too well because the certificates need to be verified frequently to make sure that the certificate has not been revoked for some reason. This centralized verification service can be a performance bottleneck in a large PKI system.
It is known from US 2001/0,019,614 [1] a dynamic key manager operable to generate an encryption key having an encryption key identification. The system also includes an information database operable to store a data entity encrypted by the encryption key. The information database is further operable to store the encryption key identification in association with the data entity. US 2001/0,019,614 features a dynamic key manager where keys are stored in a separate database which is isolated from the information database. Here, encryption keys are dynamic in that expired keys are replaced as data is retrieved.
When using prior art authentication and authorization solutions in distributed data management systems, problem arises in a scenario where a networked device such as smart phone has a physical database that has been created by the owner of the device. The creator of the physical database in many cases automatically gets the administrator rights to all objects of the database. Later, a new logical database such as a replica database may be created inside this physical database, for example as a database. This replica database may have a partial copy of data of a business application such as “electronic wallet” or “e-wallet.” Now, according to solutions of the prior art, the creator of the physical database has full access to the copy of data of a critical application as well as to the synchronization functions of the database. This in many cases is not acceptable from system security viewpoint because the administrator of the local physical database should not have any manual access to the data of the newly created replica database. That database is meant to be remotely managed. Moreover, all access to the replica data should be only through applications that have been approved by the administrator of the distributed system.
The following example illustrates the problem further. In this example, Open Database Connectivity (ODBC) or its java-based equivalence as well as an extension to Structured Query Language (SQL) are used here as an Application Programming Interface (API). In this example Intelligent Transaction [2] based propagation means that a transaction is created in the replica database and it is re-executed later at the master when the databases are synchronized. The current security model for security material management and application access control allows following sequence of actions in the replica database:                1) Login to the replica database server from any ODBC/JDBC capable SQL Editor tool using probably well known userID and password of the local Database Administrator (DBA);        2) Access the data of a catalogue representing a replica database by setting the current catalogue to be a catalogue of the replica database, e.g.                    SET CATALOGUE REPLICA_OF_E_WALLET                        3) Create manually an Intelligent Transaction that deposits electronic money to the account of the user. This transaction is later propagated to the master database, e.g.                    SAVE CALL DEPOSIT_MONEY (‘123456’, 1000000.00)            COMMIT WORK                        4) Next synchronization will now send an unauthorized transaction, i.e. the above intelligent transaction that has been created manually, outside an authorized application, to the master database.        
When using the security model of prior art there emerges a risky scenario that the above-mentioned sequence of actions in the replica database easily compromises the data integrity of the master database. In this particular example, a user may be able to deposit electronic money for himself without proper authentication and authorization, only because the user has administrator rights to the database server managing the replica database of the e-wallet system. This problem is the consequence of accepting transactions from unauthorized sources, e.g. applications such as SQL Editor (Structured Query Language Editor) which may have access to the database and perform manual data manipulation operations on the data of the database.
At the same time there arises another problem how to manage the security material such as public and private keys of the entire database topology of the system, especially in case of complex synchronization topologies in question. These complex database topologies can be for example multi-tier hierarchies and multi-master topologies. Multi-tier database hierarchy has more than two tiers of databases. For example, in a distributed sales support system, the topmost master database may have regional replicas and each regional replica may have multiple replicas of its own, e.g. one in each workstation of members of mobile sales force. In multi-master topology, one database server can contain replica databases of multiple master databases. For example, a database server of a smart phone may have a replica database of a streaming content database and a mobile sales support system. Each of these databases require their own security material that has to be managed in coordination with other, related databases. For example, to facilitate encrypted communication between a master and replica database, public encryption key of the master database needs to be delivered to the replica database and vice versa.
FIG. 1 illustrates the standard User-ID-based relational database authentication and authorization scheme according to prior art. In that scheme, each user 15, 16, 17 can be assigned one or multiple roles 151, 161, 171. Each role 121, 122, 131, 132, 141, 142 can be granted access rights to various operations 1211, 1221,1311, 1321, 1411, 1421 on the database objects 12, 13, 14 (e.g. tables) of the database. The operations on a table 12, 13 can be                Select (read data from the table)        Insert (add a new row to the table)        Update (modify a row in the table)        Delete (remove a row from the table)        
Stored Procedures 14 of the database may be granted Execute rights.
The access to the database objects (i.e. authorization) is determined upon authentication, i.e. when the user logs 11 on to the database server 10.
The main problem in this kind of authentication and authorization method is that if there are multiple applications accessing different tables in the same database, separate userID and password for login is needed for each kind of application. Managing these userID can get very complex, if the system consists of large number of applications and databases.
Additionally, authorization at database object level is often not practical. If the user manages to log on to the database using e.g. a general purpose SQL editor that allows manual read and write access to the data, the user may be able to generate transactions that are not valid ones even if strict table-level access control is in use. To prevent such logons and creation of manual transaction, the userID and password must be hidden inside the business applications that are authorized to access the data. This constitutes a security risk because often the hidden userID and password are relatively easy to extract from the application program.